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FOREWORD 


The Software Engineering Laboratory (SEL) is an organization sponsored by the 
National Aeronautics and Space Administration/Goddard Space Flight Center 
(NASA/GSFC) and created for the purpose of investigating the effectiveness of 
software engineering technologies when applied to the development of applications 
software. The SEL was created in 1977 and has three primary organizational 
members: 

NASA/GSFC, Systems Development Branch 

The University of Maryland, Computer Sciences Department 

Computer Sciences Corporation, Systems Development Operation 

The goals of the SEL are (1) to understand the software development process in 
the GSFC environment; (2) to measure the effect of various methodologies, tools, 
and models on this process; and (3) to identify and then to apply successful devel- 
opment practices. The activities, findings, and recommendations of the SEL are 
recorded in the Software Engineering Laboratory Series, a continuing series of 
reports that includes this document. 

The major contributors to this document are 

Linda O. Jun (GSFC) 

Susan Ray Valett (GSFC) 

Single copies of this document can be obtained by writing to 

Systems Development Branch 
Code 552 

Goddard Space Flight Center 
Greenbelt, Maryland 20771 


5896 


« « 

«6 | L* _ W fENHONAUM ilMK 


iii 


PRECEDING PAGE BLANK NOT FILMED 




ABSTRACT 


This doc ument discusses a particular porting effort and gives various statistics on 
analyzing the portability of Ada and the total staff months (overall and by phase) 
required to accomplish the rehost, and compares this effort to past experiments on 
the rehosting of FORTRAN systems. The discussion includes an analysis of the 
types of errors encountered during the rehosting, the changes required to rehost 
the system, experiences with the Alsys IBM Ada compiler, the impediments en- 
countered, and the lessons learned during this study. 
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EXECUTIVE SUMMARY 


E.l INTRODUCTION 

One of the major goals of Ada was to eliminate the proliferation of language dia- 
lects by standardizing a defined Ada syntax. The defined syntax was expected to 
greatly reduce the level of effort required to port an Ada system from one environ- 
ment to another. To better understand the issues of portability, a rehost study was 
conducted in the Software Engineering Laboratory (SEL) at the National Aeronau- 
tics and Space Administration/Goddard Space Flight Center (NASA/GSFC). An 
operational software system consisting of 90,000 lines of code was ported from a 
VAX 8810 to an IBM 4341. 

E.2 OBJECTIVE AND SCOPE 

The rehost study was meant to be a concise, self-contained experiment on porting 
an Ada system. It had the following three objectives: 

• Determine the effort required to rehost an operational Ada system 

• Quantify the effort characteristics of each element of the rehost effort 

• Identify and document subjective impressions, problems, and lessons 
learned 

E.3 RESULTS 

The following statements summarize the results of the rehost study: 

• The study took a total of 133 staff-days over a 10-month period. 

• Compilation took 38 percent of the total effort, and testing took 29 per- 
cent. 

• At the end of the study, 6.4 percent of the total components were new, 
and 18 percent of the the total components were changed. 

• Ten test cases were executed, and the majority of them passed success- 
fully. (The test failures were due to compiler anomalies.) 

• The majority of the problems encountered during the effort were due to 
the immaturity of the particular compiler employed on the target system. 

E.4 CONCLUSION 

The following statements summarize the conclusions drawn from the rehost study: 

• Subjectively, the effort required to rehost an Ada system seemed to be 
less than that required to rehost a similar FORTRAN system. 

• The rehost effort was considered a success in that all objectives were 
met. 

xi 
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• The Ada compiler employed was not yet mature enough to support the 
development of large-scale flight dynamics software systems. 

• Debugging was difficult and expensive due to time-consuming recompila- 
tions and the lack of a debugging tool. 

• Vendor-provided features caused fewer problems than expected. 

• User-defined data types were an Ada feature that made the rehost effort 
easier. 
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SECTION 1-INTRODUCTION 


One of Ada’s primary goals was to eliminate the proliferation of both new lan- 
guages and the numerous dialects of existing languages by standardizing Ada’s 
defined syntax. It was anticipated that a “standard” common language could be 
defined and made resident on all software platforms. Most studies of Ada have 
been concerned with whether Ada improves the levels of productivity, reliability, 
and maintainability; only a few studies have been conducted on the issue of port- 
ability (Branyan, 1987; Engle, 1988). To better understand the issues of portability 
of an Ada system, a rehost study was conducted in the National Aeronautics and 
Space Administration/Goddard Space Flight Center (NASA/GSFC) Flight Dynam- 
ics Division’s (FDD) Software Engineering Laboratory (SEL). 

1.1 OBJECTIVES AND SCOPE 

The study had three objectives: (1) to determine the effort required to rehost an 
operational Ada system from one environment to another; (2) to quantify the ef- 
fort characteristics of each element of the rehost effort (file transfer, compiling, 
linking, execution, and accuracy); and (3) to identify and document subjective im- 
pressions, general problems, and “lessons learned” to use for future rehost 
projects. No performance issues were considered, and no environment compari- 
sons were made. The study was meant to be a concise, self-contained experiment 
on porting an Ada system. 

1.2 BACKGROUND OF REHOSTED ADA SYSTEM 

GOESIM, the telemetry simulator for the Geostationary Operational Environmental 
Satellite (GOES), was the system chosen for rehosting. The simulator models 
attitude and sensor information from a satellite and transforms it into various out- 
put formats to be used to test other software systems. Initially developed on a 
VAX 8810 in Digital Equipment Corporation (DEC) Ada, the system was ported to 
a National Advanced Systems (NAS) 8063 (comparable to the IBM 3081) with an 
Alsys IBM Ada compiler, Version 3.6. The system contains approximately 
90 thousand source lines of code (KSLOC) (physical lines), about 50 percent of 
which were blanks or comments. The system comprised the following 550 compo- 
nents: 


• Generic package specifications and bodies: 41 

• Package instantiations: 14 

• Package specifications and bodies: 116 

• Separately compilable subprograms: 373 

• FORTRAN routines: 6 
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Development on the VAX required 72 staff-months over a period of 23 months. 
Effort expended by secretaries, managers above task manager, and librarians was 
not included in this figure and is not used in this document. The relative complex- 
ity of the system was considered average. No plans for rehosting had been fac- 
tored into any aspect of the development. Consequently, the simulator made use 
of some VAX-specific features: for instance, the Direct_Mixed_IO package was 
used for input/output (I/O). 
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SECTION 2-REHOST OVERVIEW 


This section describes the groundwork that was completed before the actual rehost 
began. This work included creating and analyzing the questionnaire, meeting with 
development personnel to overview GOESIM, and planning the steps necessary for 
the rehost. 

2.1 QUESTIONNAIRE 

Before the rehosting effort began, a questionnaire was distributed to 31 software 
developers, researchers, and managers across the flight dynamics development/ 
research environment. The questionnaire was intended to capture software person- 
nel’s general expectations regarding the “portability” characteristics of Ada 
software. A copy of the questionnaire is provided as Appendix C. 

2.1.1 Description 

The questionnaire included a precise description of what constituted a successful/ 
completed rehosting effort. The activities listed in the questionnaire included file 
transfer, compilation, linkage, execution, testing, and a draft of the final report. 

The 24 people who responded ranged from junior programmers with less than 
5 years’ experience to senior managers with 15 years’ experience. Some respon- 
dents had Ada experience and some had none, but all were familiar with the flight 
dynamics environment. Figure 2-1 shows the level of experience of the question- 
naire respondents. Approximately 54 percent of the respondents had little or no 
experience with Ada, 95 percent had a good knowledge of software development, 
82 percent had a good knowledge of the VAX, and about 59 percent had little or 
no experience with the IBM environment. 



Figure 2-1. Respondents’ Levels of Experience 
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The rehost effort was carried out by two people working half time. The team had 
worked well together in the past. The first team member’s level of experience at 
the start of the rehost is characterized as follows: 

Ada Advanced 

SAV Development Expert 

VAX Environment Expert 

IBM Environment Expert 

The other team member’s experience is characterized as follows: 

Ada Novice 

SAV Development Advanced 

VAX Environment Advanced 

IBM Environment Advanced 

2,1,2 Results From the Questionnaire 

The respondents were asked about their expectations concerning major problems, 
effort expenditure for each phase of the rehost effort, and percentage of modules 
requiring modification. Of the 31 questionnaires distributed, 24 were completed 
and returned. 

2. 1.2.1 ESTIMATES OF THE TOTAL EFFORT 

The average estimated total effort was 168 staff-days, and estimates ranged from 
41 to 580 staff-days (Figure 2-2). The majority of respondents thought that pre- 
paring software and compilation would take more than 50 percent of the total 
effort. People with more knowledge in Ada (advanced or expert) estimated a 
higher total effort (240 days) than people with less knowledge in Ada (none or 
novice: 108 days). 

2. 1.2.2 PERCENT OF MODULES CHANGED 

The questionnaire asked what percentage of modules would require changes (Fig- 
ure 2-3). The average response estimated that close to one-third (29 percent) of 
the software modules would need to be changed. People with more experience in 
Ada estimated a lower percentage of module changes than people with less experi- 
ence in Ada (24 percent versus 36 percent). 

2. 1.2.3 EXPECTED PROBLEM AREAS 

The respondents were asked to estimate the level of difficulty for four possible 
problem areas. All four were estimated to present medium or major problems 
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Figure 2-3. Estimates of Percent of Modules Changed 

(Figure 2-4). The majority of the respondents thought that VAX-specific Ada fea- 
tures would cause major problems in rehosting the Ada system. 

2. 1.2.4 RELATIVE DIFFICULTY OF EACH PHASE 

Most respondents believed that testing and analysis would be the most difficult 
phase and linking would be the least difficult phase (Figure 2-5). Many people 
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Figure 2-4. Estimated Problem Areas 


Easy Medium Difficult 



Figure 2-5. Estimated Difficulty of Each Phase 

thought that the lack of a debugging tool would cause a major problem during 
testing and analysis. 

2. 1.2.5 TYPES OF ADA PROBLEMS 

The questionnaire asked what specific types of problems were most expected 
(Figure 2-6). The average response showed that external I/O and compiler 
implementation-dependent Ada features would be major problems. 

2,2 FINDINGS FROM THE SYSTEM OVERVIEW 

The rehost team met with the GOESIM development personnel to get a general 
overview of the project. During this time, the team identified any VAX-dependent 
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Figure 2-6. Estimated Ada Problem Areas 

Ada features, and DEC provided packages and their possible solutions, reviewed 
the design, examined the ACS library on the VAX to establish a compilation order, 
listed the component names and their correspondent source file names (since the 
IBM limited file names to eight characters), and listed the external input data files 
needed for execution. 

During the general overview of GOESIM, the team identified four VAX-dependent 
features that required special handling during the rehosting: Direct_Mixed_IO, 

VAX hardware-oriented types and functions, Math_Lib, and pragma INTERFACE 
to FORTRAN. GOESIM used Direct_Mixed_IO for reading and writing mixed 
type records from and to a direct access file. For instance, the engineering data 
file consisted of a header record, an index record, and data records, which were all 
different record types; GOESIM was required to read or write seven different di- 
rect access files. GOESIM used VAX hardware-oriented types and functions im- 
plemented in the DEC SYSTEM package for the bit manipulations necessary to 
generate simulated telemetry data. It used the DEC-provided Math_Lib generic 
package for trigonometric functions and other transcendental functions. And 
GOESIM included FORTRAN routines to compute nutation and precession of the 
equinox and to access direct-access files for obtaining solar and lunar positions. 

2.3 DESCRIPTION OF REHOST PHASES 

Rehosting comprised six phases: software preparation on the IBM, compilation, 
linkage, execution, testing/result analysis, and report preparation. The 
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questionnaire asked for estimates of efforts for each phase, and the “expected” 
effort was compared to the “actual” effort expended in the rehosting process. 

The following activities were performed in each phase: 

• Phase 1: Software Preparation 

1. Obtained general overview of GOESIM 

2. Established compilation order 

3. Created source libraries (partitioned data set and PANVALET) 

4. Transferred source files 

5. Moved source files from partitioned data set to controlled 
PANVALET library 

6. Created an Alsys Ada program library 

7. Implemented VAX hardware-oriented types and functions imple- 
mented in SYSTEM package (e.g., Bit_Array types and bit manipu- 
lation functions) 

• Phase 2: Compilation 

1. Created CLIST to submit compilation in right compilation order 

2. Compiled/recompiled/maintained Alsys Ada program library 

3. Replaced VAX-dependent Direct_Mixed_IO with standard Direct_IO 

4. Implemented Math_Lib (coded TAN, ASIN, ACOS, LOG2) because 
MathJLib was not provided by Alsys 

5. Converted six FORTRAN routines to Ada (Alsys compiler did not 
provide pragma INTERFACE to FORTRAN routines) 

• Phase 3: Linkage 

1. Bound and linked to create executable load module 

• Phase 4: Execution 

1. Converted two binary input data files to IBM format 

2. Resolved problems that occurred during execution, including com- 
piler problems 

3. Repeated code change/recompilation/linkage 

4. Executed first test without exception or abends 
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• Phase 5: Testing/Results Analysis 

1. Ran 10 test cases selected from VAX system test cases 

2. Analyzed results 

3. Resolved problems and reran test cases as needed 

• Phase 6: Report Preparation 

1. Gathered all information recorded during rehosting 

2. Wrote report describing the experience 
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SECTION 3-RESULTS 


This section presents the experiences of the rehost team with each rehost phase 
and explores the problem areas and solutions, including workarounds developed. 

3.1 FINDINGS OF EACH REHOST PHASE 

3.1.1 Software Preparation 

During the software preparation phase, an electronic transfer utility was used to 
move GOESIM source files to the IBM from the VAX. Source files were moved 
into members of a partitioned data set. Later, these members were moved to a 
controlled PANVALET library. 

Before a compilation of the 540 Ada components was attempted, the team encoun- 
tered problems with compilation order. Component listings from the VAX “ACS 
show program/portability” command were very helpful in determining the compila- 
tion order. Nevertheless, several attempts were made before all the package speci- 
fications were successfully compiled. 

3.1.2 Compilation 

At the beginning of the compilation phase, the team repeatedly encountered occur- 
rences of library corruption due to abends caused by insufficient central processing 
unit (CPU) or disk space specified. This in turn required the team to recreate the 
library and recompile the source units. In the middle of the compilation phase, the 
Ada program library had to be reinitialized with a larger size, since more compo- 
nents were compiled into the library. 

Estimating the disk space required for the program library was difficult. The 
library was initially allocated to 12,000 blocks; ultimately, 25,000 blocks were 
needed to complete the compilation successfully. The team tried to avoid overesti- 
mating the size of the program library, since the size affected the compilation 
speed. They first attempted to create multiple libraries with smaller sizes, since 
the larger the library, the longer compilation took, but they were not successful due 
to problems with the Alsys Ada unit manager. Since the Alsys IBM Ada compiler 
Version 3.6 did not provide automatic recompilation, submitting jobs for recom- 
pilation for each unit was time consuming and tedious. Later, this recompilation 
effort was reduced by creating a CLIST to submit compilation in the right compila- 
tion order and by routinely backing up the Alsys Ada program library. Normally, 
one compilation completed within the range of 4 to 160 CPU seconds, or 3 to 
140 minutes wall-clock time, depending on the size of the compilation unit and the 
system workload. 

3.1.3 Linkage 

Binding and linking were attempted during the linkage phase, and went extremely 
well once all the components were successfully compiled. Normally, binding took 
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most of the CPU time (approximately 65 CPU seconds), while linking was rela- 
tively fast (about 2 CPU seconds). 

3.1.4 Execution 

Execution was hindered by the compiler problems and GOESIM software errors. 
The first attempt to execute the rehosted system was terminated abnormally by a 
problem in the initialization of record type variables. After a great effort to isolate 
it, the problem was found in the compiler. Some uninitialized variables in the 
software caused delays in successfully executing the system. The execution phase 
was terminated by executing the first test case without analysis of the output re- 
sults. Before starting the testing phase, the team had to update the GOESIM soft- 
ware, since the source files were moved to the IBM before its completion on the 
VAX. This effort was necessary in order to compare results from the IBM to 
results from the VAX; however, it was not included in the actual rehosting effort. 

3.1.5 Testing 

During the testing phase, 10 test cases were selected and executed from the 30 ac- 
ceptance test cases on the VAX. These test cases covered the testing of the major 
functions of the system and all input and output files. The output results were 
compared against the results from the VAX, and they matched to an acceptable 
level of accuracy. The problems encountered during testing were caused by 
Direct_IO and bit manipulation types and functions. The replacement of VAX- 
dependent Direct_Mixed_IO by standard Direct_IO worked well, in general, except 
for one input file. Due to problems with Alsys Direct_IO, the rehosted system was 
not able to read the file correctly even with the use of a record representation 
clause. The bit manipulation functions that the team replicated on the IBM gave 
incorrect results in the simulated telemetry data because the most significant bit 
and least significant bit were reversed from the implementation on the VAX. 

3.2 PROBLEM AREAS AND SOLUTIONS 

This section describes each problem area, the problem resolutions, and the number 
of components that were affected by problems during this particular porting effort. 
All the changes made to the software are categorized into the following problem 
areas: 


• VAX-specific features 

• Anomalies with the Alsys compiler 

• Size limitation of the compiler 

• Adaptation to the IBM/MVS environment 

• Rehosted software errors 

• Compiler implementation-dependent features 
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3.2.1 VAX-Specific Features 

Use of VAX-specific features required major component changes. VAX-specific 
features included Direct_Mixed_IO, pragma INTERFACE to FORTRAN routines, 
F-/D-/G-floating point, VAX hardware-oriented types and functions provided in the 
package SYSTEM, and a predefined Math_Lib package. Twenty-seven compo- 
nents using Direct_Mixed_IO had to be changed to use Direct_IO instantiations, 
and 19 components were added for instantiating Direct_IO with appropriate file 
types. Direct_Mixed_IO was replaced with Direct_IO because replacement was 
thought to be a straightforward implementation that would require less effort than 
implementing the Direct_Mixed_IO package body, which contains 15 subprograms. 
An alternative method of implementing Direct_Mixed_IO would be to use Un- 
checked Type Conversions. This method would reduce the number of Direct_IO 
instantiations to five, but it could cause more difficulties in debugging and could 
give erroneous results. All other VAX-dependent features were replicated on the 
IBM, although some took longer to implement than expected due to compiler 
errors (Math_Lib) and reversed bit order of VAX hardware-oriented type 
(Bit_Array_8), a hidden implementation of the DEC Ada compiler. Six 
FORTRAN routines were converted to Ada, since Alsys supported INTERFACE to 
ASSEMBLER only. 

3.2.2 Anomalies With Alsys Compiler 

The rehost team found a total of five problems with the Alsys IBM Ada compiler 
Version 3.6 during rehosting. Four were found during execution and one was 
found during testing. Most of these problems were very difficult to isolate, as the 
team had to find the problems within the code. In all, 17 components were 
changed due to these compiler anomalies. 

The following are the Alsys IBM Ada compiler Version 3.6 problems found during 
rehosting: 

• Incorrectly evaluates “EF A >=1.0” or “IF A <= 0.0” 

• Raises exception “SPURIOUS_ERROR” due to branch to odd address 
when initializing variant record type variables 

• Incorrectly raises “NUMERIC_ERROR” in INTEGER computation 

• Skips first record when reading Direct Access file written by non-Ada 
program 

• Incorrectly reads Direct Access file starting with INTEGER, even with 
record representation clause 

3.2.3 Compiler Size Limitation 

The rehost team encountered compiler size limitation problems when compiling 
two packages. One package used more than the allowable size (1,024 bytes) for 
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each variant part of the record type. This problem was resolved by changing the 
maximum size and adding a new variant part for the 3x3 matrix. The other pack- 
age body contained three instantiations of various generic packages that caused 
STORAGEERROR. This problem was resolved by making each instantiation a 
separate library unit. 

3.2.4 Adaptation to IBM/MVS Environment 

Several changes were necessary to adapt to the IBM/MVS environment. Several 
components, such as RECORD_FORMAT and RECORD_LENGTH in the 
“FORM” parameter, were changed to comply with the IBM/MVS file attributes, A 
change was also made to resolve NAME_ERRORs when creating files with dupli- 
cate names. (The VAX allows the creation of files with duplicate names; it will 
create the new file with a different version number.) Ephemeris_Type package 
had to be changed to declare an Extended Binary Coded Decimal Interchange 
Code (EBCDIC) string instead of an American Standard Code for Information 
Interchange (ASCII) one in order to read the IBM-resident GOES ephemeris file. 
Some of the “/=” test had to be rewritten to add a tolerance range to resolve 
precision problems when comparing double precision numbers to single precision 
numbers. 

3.2.5 Rehosted Software Errors 


Several changes were made to incorporate error corrections in GOESIM software. 
One software error that should have been caught by the VAX DEC Ada Compiler 
during compilation was an array aggregate with an OTHERS choice for an uncon- 
strained array. Some other problems encountered were due to variables not being 
initialized, and CONSTRAINT_ERRORs raised during the writing of debug output 
or long error messages. 

3.2.6 Compiler Implementation-Dependent Features 

Problems with the Alsys compiler implementation-dependent characteristics were 
minor. Changes required due to different predefined floating-point type names 
between the VAX and the IBM were localized to only three components because 
GOESIM declared its own floating-point data types and used them consistently 
throughout the system. Use of pragma PACK was ignored by the Alsys compiler, 
which eliminated some component changes. One component changed due to a 
minimum size requirement of 16 bits on the IBM for the type “UNSIGNED_BYTE 
IS RANGE 0..255”, which required only 8 bits on the VAX. 

3.3 REHOST STATISTICS 

During the rehosting, the rehost team kept detailed statistics of the entire effort, 
including problems. These statistics were gathered monthly and distributed in 


3-4 


5396 


status reports (see Appendix D). The total statistics were gathered when the 
testing phase was complete and were rearranged to better present the rehosting 
effort. The subsequent sections present detailed statistics on effort, schedule, com- 
ponents changed/added, and time spent on problem areas, by phase. It should be 
noted that the compilation phase also included other activities, such as resolving 
VAX-dependent features and creating CLISTs to ease recompilation. 

3.3.1 Total Effort for Each Phase 

The following charts show the total effort required in staff-days to successfully 
complete each phase (Figure 3-1) and the schedule during the rehost study (Fig- 
ure 3-2). It took a total of 133 staff-days over a 10-month period to complete the 
rehost up to the first draft of the report. As shown in Figure 3-1, 51 staff-days 
(38 percent of the total effort) were spent in the compilation phase and 38 staff- 
days (29 percent) were spent in testing. 

3.3.2 Breakdown of Total Effort by Activity 

A breakdown of the effort spent in each activity is shown in Figure 3-3. The 
CODE activity included 

• Conversion of FORTRAN to Ada 

• Implementation of MathJLib, VAX hardware-oriented types, and func- 
tions 

• Code changes and new code 



Phase 

Staff Days 

Prepare S/W 

16 

Compile 

51 

Link 

2 

Execute 

18 

Test 

38 

Draft Report 

8 

Total 

133 


1 .5% Link 

Figure 3-1. Effort To Complete Each Phase 
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Figure 3-2. Rehost Schedule 



Figure 3-3. Total Effort by Activity 

The OTHER activity included 

• Transfer of source files and data files 

• JCL and CLIST generation 

• Input data file conversion 

• Monthly status reports and SEL forms 

• Ada library maintenance 
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The TESTING activity included both the integration testing and system testing, and 
DEBUGGING included all the debugging activity involved throughout testing. 

3.3.3 Breakdown of Effort by Phase 

Table 3-1 shows the breakdown of each activity for each particular phase. 

Table 3-1. Staff Effort by Phase 



Prepare 

Software 

Compile 

Link 

Execute 

Test 

Report 

Total 

Code 

16.4 

36.3 


1.9 

10.9 


65.5 

Compile/Test 

30.9 

154.6 

12.1 

33.7 

20.5 


251.8 

Debug 


50.0 


44.2 

85.8 


180.0 

Test 




7.4 

86.1 


93.5 

Report 





34.4 

62.2 

96.6 

Other 

77.4 

164.8 

3.6 

55.2 

70.2 

3.3 

374.5 

Staff-Hours 

124.7 

405.7 

15.7 

142.4 

307.9 

65.5 

1,061.9 


3.3.4 Components Changed/Added by Phase 

At the end of the study, GOESIM consisted of 564 components; 102 were changed, 
and 45 were added (9 components out of the 45 were made separate compilable 
units to ease debugging). Of the 102 components changed, 66 percent were 
changed during compilation, 18 percent were changed during execution, and 
16 percent were changed during testing. Of the 45 new components, 75.5 percent 
were from compilation, 15.5 percent were from execution, and 9 percent were 
from testing (Figure 3-4). 

3.3.5 Components Changed/Added in Each Problem Area 

Figure 3-5 and 3-6 show the components changed and added as a result of resolv- 
ing various types of problems. As shown in the figure, major changes were re- 
quired due to VAX-specific features. A total of 44 components were changed, and 
32 components were added to resolve VAX-dependent features. To ease debug- 
ging of the system, nine components were separated from the package body, which 
reduced the recompilation effort. 

3.3.6 Time Spent in Each Problem Area 

Figure 3-7 shows the effort spent in each problem area during rehosting. A total 
of 27 staff-days were spent fixing problems and eliminating VAX-dependent 
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Compiler Size 
Limitation 



VAX-Spedfic Features 

O 


O) 

8 

Figure 3-6. Components Added 



Figure 3-7. Effort Spent in Each Problem Area 


features. As shown in the figure, more time was spent fixing unexpected prob- 
lems, such as compiler errors and software errors, than on known problems, such 
as removing VAX-dependent features and adapting to the IBM/NWS environment. 
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3.4 SUMMARY RESULTS 


Except for working around the problems with the Ada program library, the first 
three phases of the rehosting went smoothly. Transfer of source files and data 
files went without difficulty via the electronic file transfer utility. Compilation 
itself went rather smoothly, as 99 percent of the system was successfully compiled 
after correcting two components with size limitation errors. Linkage went 
extremely well; the system was linked during the first attempt. However, execu- 
tion and testing were rather difficult due to errors with the software and the com- 
piler. 

The statistics collected during this experience are summarized below according to 
the phases in which they occurred. 

• Phase 1: Source and Data File Transfer 

Source files transferred: 540 (some files were not used on IBM) 
Input data files converted to IBM format: 2 
Input data files transferred: 35 
Major problems: None 

• Phase 2: Compilation 

Components compiled: 564 

New components added: 36 (6.4%, 1,970 LOC) 

Components separated from the package body: 9 (1.6%) 
Components changed: 102 (18%) 

Average compilation speed: 1,295 lines/minute 
Major problems: Library corruption, compiler limitation 

• Phase 3: Linkage 

Attempts made to successfully link: 1 
Average bind/link speed: 64.20 CPU seconds 
Major problems: None 

• Phase 4: Execution 

Number of attempts to successfully execute first test: 26 
Major problems: Compiler errors, software errors 
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• Phase 5: Testing 

Number of test cases executed: 10 
Number of input files successfully read: 4 out of 5 
Number of output files successfully written: 10 out of 10 
Execution speed (2-minute simulation) 

— With Direct_IO only: 69.46 CPU seconds 

-- With Text_IO only: 121.41 CPU seconds 

— With both IOs: 169.29 CPU seconds 

— Without any 10: 17.87 CPU seconds 

Accuracy of results compared to VAX: Matched to 4-5 digits 

Major problems: Compiler error, file interface 
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SECTION 4-CONCLUSION 


4.1 THE REHOST EFFORT WAS A SUCCESS 

This particular porting effort was considered a success, since the majority of the 
problems encountered during the effort were due to the immaturity of the particu- 
lar compiler employed and not to the Ada language itself. Transfer of source files 
and data files was made easy through the use of an electronic file transfer utility. 
Compilation of the Ada code was smooth: 99 percent of the system was success- 
fully compiled after resolving the problems with size limitation. However, the 
Alsys Ada program library was immature and caused many problems during the 
compilation phase until the rehost team gained more experience. Appendix B 
describes some lessons learned during this phase. Execution and testing were 
rather difficult, due to compiler problems and the recompilation necessary for de- 
bugging. 

4.2 ALSYS IBM ADA COMPILER WAS NOT YET MATURE 

Corruption of the Ada program library was one of the major problems during 
rehosting. The library became corrupted when compilation terminated abnormally 
due to CPU timeout or disk space shortage. Occasionally, the library was deleted 
when a fatal error occurred during compilation. Another major problem was inter- 
facing with Random_Access file (DirectJD). The rehosted system was not able to 
read one of the input files correctly without any changes to the code. It was 
determined that the particular file type package specification had to be rewritten to 
include Record Representation Clause. The Alsys IBM Ada compiler automatically 
rearranges record components if no component clause is given. However, this was 
not attempted, since massive recompilations would have been required and it 
would have taken a fair amount of time to write Record Representation Clause for 
the record. It was later determined during unit testing that this fix would not 
eliminate the problem. Other compiler errors described earlier had a severe im- 
pact on the rehosting. 

4.3 DEBUGGING AND RECOMPILATIONS WERE DIFFICULT 
AND COSTLY 

Aside from the compiler problems, debugging was one of the most difficult and 
costly activities of the rehost. Debugging was difficult due to a lack of knowledge 
about the rehosted software and costly because of the time-consuming recompila- 
tions that were necessary. For instance, the Minor_Frame package had 72 sub- 
units; if that package body was recompiled, all 72 subunits were automatically 
deleted and therefore had to be recompiled. This problem was most severe when a 
type package that was “withed” in other package specifications was recompiled, 
because all dependent package bodies and subunits were deleted. To solve 
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compiler errors and to update the software, several type packages had to be recom- 
piled. Debugging caused several package bodies to be recompiled. Developing an 
Ada system is a high-cost proposition: in order to enforce the language rules, the 
compiler or compiling environment has to maintain information on each compila- 
tion unit in the Ada program library, which greatly increases the system workload. 
Therefore, Ada systems must be designed and implemented in a way that reduces 
the compilation cost. The following are some suggestions: 

1. “With” in library units at the lowest unit (subunit) possible 

2. Group a smaller number of functions into library packages rather than 
using one big general package 

3. Make subunits instead of implementing within the package body 

Other factors that made debugging more difficult were the lack of a debugging tool 
for the IBM and insufficient error messages generated by the rehosted software 
system. For instance, some exceptions were not handled properly at the lower 
level unit. The exception was propagated up to the main program and “irrecover- 
able error” was written out. Debugging would have been easier if GOESIM had 
written detailed error messages when an exception was raised at the lower level 
unit, before propagating it to the higher level unit. 

4.4 VAX -DEPEN DENT FEATURES CAUSED FEWER 
PROBLEMS THAN EXPECTED 

The rehost team expected that the VAX-dependent features— Direct_Mixed_IO, 
predefined Math_Lib, hardware-oriented bit manipulation types and functions, 
etc.— would cause major problems. However, the bit manipulation in the Simulate 
Telemetry Da ta went smoothly, although i t g enerated double-sized records due to 
the implementation of the Alsys compiler. As described earlier, nonstandard 
Direct_Mixed_IO was replaced with standard Direct_IO, and the rehost team suc- 
cessfully tested four of five input files. It was a surprise to find that the Alsys 
compiler did not provide a predefined MathJLibrary containing transcendental 
functions; some of the functions had to be implemented by the rehost team. 

4.5 COMPARING ADA REHOSTING WITH OTHER 
LANGUAGES 

It is not clear from the results of this rehost effort whether a system written in Ada 
is more portable than a system written in any other language. A similar system 
written in another language, like FORTRAN, should be rehosted for comparison. 
Nonetheless, porting this particular Ada system was not too difficult. The relative 
ease of rehosting is based on the software characteristics of the rehosted system. 
The rehosted system was a telemetry simulator (which was essentially data trans- 
formation) and required a simple, noninteractive user interface, which makes a 


4-2 


5396 



porting effort less difficult. A large interactive user interface is generally believed 
to be less portable because of hardware dependencies. 

Although the SEL has never collected data on a software system rehost, the FDD 
has rehosted FORTRAN systems in the past. From this experience an attempt can 
be made to estimate the effort involved in rehosting a system like GOESDvI that is 
developed in FORTRAN. Table 4-1 illustrates the SEL’s estimated effort to rehost 
a FORTRAN telemetry simulator and compares it to the actual results from the 
GOESM rehost. (The subjectivity of this comparison is acknowledged. Flowever, 
in the absence of a similar empirical comparison to draw from, the authors felt 
that the inclusion of a subjective comparison would benefit the reader.) 

Table 4-1. Comparative Effort to Rehost FORTRAN and Ada Telemetry 
Simulators 



FORTRAN 

Estimated 

Ada 

Actual 

Total Effort (Staff-days) 

198-220 

125* 

Percent of Effort to Complete: 



Prepare Software 

20% 

13% 

Compile 

20% 

41% 

Link 

5% 

2% 

Execute 

10% 

14% 

Test 

45% 

30% 


* 

This number does not include effort spent on the report. 


The FORTRAN estimates were derived in the following way: 

1. The SEL has observed a ratio of approximately 3:1 between Ada and 
FORTRAN SLOC. (LOC in this case refers to the physical lines.) 

2. The SEL also has an average FORTRAN productivity of 5 KSLOC per 
staff-year. Therefore, 6 to 7 staff-years would have been the expected 
time required to complete a comparable FORTRAN system. 

3. Finally, in past FORTRAN rehostings, the SEL has documented a ratio of 
6:1 for the number of years to develop a FORTRAN system compared to 
the years to rehost one. Therefore, the SEL would expect a rehost effort 
of 12 to 14 staff-months. However, this 6:1 ratio is based on 1984 
technology. In 1989, FORTRAN compilers on the VAX and the IBM 
were more similar to each other than in 1984. Hence, the SEL would 
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expect a 25 percent improvement in the effort to rehost, and the rehost 
effort estimate would drop to 9 to 10 months. 

The breakdown of the effort required for each phase is a result of the experience 
gained from past FORTRAN rehostings, updated to reflect the advantages (i.e., 
recently completed system to rehost, access to developers, documentation, etc.) 
found in this rehost. 

4.6 SOME ADA FEATURES PROMOTE PORTABILITY 

Aside from the software characteristics issue, it is clear from the study that some 
Ada features promote portability. During the rehost, the most appealing features 
were abstract data types, packages, and descriptive names. Use of user-defined 
data types was one of the features that made the rehost effort easier. For instance, 
instead of using predefined floating-point types, user-defined real types were used 
consistently throughout the system. For example 

type REAL is digits 6 

type REALJLONG is digits 15 

This was beneficial, because the compiler could choose the proper implementation. 

The use of packages did not make the system more portable but aided in compre- 
hending the physical structure of the system. In fact, use of packages increased 
compilation effort because of Ada visibility rules. Use of enumeration types and 
descriptive names for types, packages, subprograms, and objects made code more 
readable, and consequently less time was spent referring to documentation or other 
units, since code review was essential during debugging. 
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APPENDIX A-ADA COMPILER CHARACTERISTICS 


DEC Ada Compiler Version V5 versus Alsys IBM Ada Compiler Version 3.6 


VAX (DEC) IBM fAlsvs) 


Predefined Types 


_ 

SHORTFLOAT 

No 

6 digit (32 bit) 


FLOAT 

6 digits (32 bit) 

15 digit (64 bit) 


LONG FLOAT 

9, 15 digit (64 bit) 

18 digit (128 bit) 

— 

LONG_LONG_FLOAT 

33 bit 

No 


SHORT_SHORT_INTEGER 

8 bit 

No 


SHORT_INTEGER 

16 bit 

16 bit 


INTEGER 

32 bit 

32 bit 

— 

Predefined Praema 
CONTROLLED 

Yes 

No 


INTERFACE 

Assembler/FORTRAN* 

Assembler 


MEMORY_SIZE 

Yes 

No 


OPTIMIZE 

Yes 

No 


PACK* 

Yes 

No 

— 

STORAGE_UNTT 

Yes 

No 


S YSTEM_NAME 

Yes 

No 


Predefined Packaaes 
Direct_Mixed_IO * 

Yes 

No 


Record_IO 

No 

Yes 


Math_Lib* 

Yes 

No 


ASCII_To_EBCDIC 

No 

Yes 

— 

EBCDIC_To_ASCII 

No 

Yes 



Utilities 

Ada Program Library Facility 

Yes 

Yes 

- 

Symbolic Debugger 

Yes 

No 


* Used in GOESIM on the VAX but not available on the IBM. 
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APPENDIX B— DEVELOPING ADA SYSTEMS FOR IBM/MVS 


The following list contains some suggestions for developing Ada systems in an 
IBM/MVS environment using the Alsys IBM Ada Compiler Version 3.6: 

1. Document the compilation order. This is essential to an Ada system. 

2. Create a CLIST to compile the whole system as early as possible, since 
recompilation is often necessary. 

3. Create an Ada Program Library with ample size to avoid redundant com- 
pilation effort due to space shortages. (An Ada system of 92 KSLOC 
with 564 components needed 25,000 blocks.) 

4. Use another, smaller Program Library for unit testing. Units in the main 
Program Library can be referenced by the ACQUIRE command from the 
Ada Unit Manager. This will be a more efficient way of unit testing, 
since only the testing unit or the unit being tested is required to be in the 
other Program Library. 

5. The main Program Library should be backed up routinely to restore a 
corrupted library. 

6. The following workaround is recommended when generating Ada code to 
avoid some compiler problems: 

a. Code “A >= B” as “A > B or A = B” for floating-point number types 

b. When creating a record format for a random access file, all FLOAT 
items should be placed before items of type INTEGER 

7. If an Ada system needs to read a random access file written by a non- 
Ada program, rewrite the file with the first record duplicated, since 
Direct_IO skips the first record of a non- Ada file. 


B-l 


5896 


PRECEDING PAGE BLANK NOT FILMED 





APPENDIX C— QUESTIONNAIRE FOR GOESIM REHOSTING 


Name: 


1. What is your level of experience with the following? 




SAW * 

VAX* 

IBM* 


Ada 

Development 

Environment 

Environment 

None 

□ 

□ 

□ 

□ 

Novice 

□ 

□ 

□ 

□ 

Advanced 

□ 

□ 

□ 

□ 

Expert 

□ 

□ 

□ 

□ 


* Independent of Ada 

2. Please estimate total effort In staff-days required to complete the following: 


Preparing S/W on the IBM: 

Staff-days 

Successful compilation: 

Staff-days 

Successful linkage: 

Staff-days 

Successful execution: | 

Staff-days 

Successful testing: 1 

Staff-days 

Documentation - A short report | 

Staff-days 


Total: 


Staff-days 


(Successful means no diagnostics/error for that step) 


3. What will be the major area of problems In rehosting? 


(Check one box for each area of problems.) 





Major 

Medium 

Minor 

None 

Anomalies with Alsys 
Compiler on the IBM 

□ 

□ 

□ 

□ 

DEC VAX-specific Ada features 
used In the simulator 

□ 

□ 

□ 

□ 

IBM/MVS environment for Ada 
(JCL, EBCDIC, data files, etc.) 

□ 

□ 

□ 

□ 

Availability of S/W support 
library on IBM (e.g. MathJJb) 

□ 

□ 

□ 

□ 

Other: 

(Specify) 

□ 

□ 

□ 

□ 
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4. What will be the relative difficulty of each phase? 
(Check one box for each phase.) 



Easy 

Medium 

Very Difficult 

Preparing S/W on IBM 

□ 

□ 

□ 


(setting up files, etc.) 
Compilation 

□ 

□ 

□ 


Linking 

□ 

□ 

□ 


Testing and analysis 

□ 

□ 

□ 


What types of Ada problems would you expect 

to have? 



(Check one box for each type.) 

Major 

Medium 

Minor 

None 

Interface (external I/O) 

□ 

□ 

□ 

□ 

Interface (internal - module to 
module) 

□ 

□ 

□ 

□ 

Computational 

□ 

□ 

□ 

□ 

Initialization 

□ 

□ 

□ 

□ 

Data typing 

□ 

□ 

□ 

□ 

implementation-dependent 

□ 

□ 

□ 

□ 

Ada features (Pragma, 
Attributes, Exception, etc.) 





Variable names 

□ 

□ 

□ 

□ 

Logic/control structure 

□ 

□ 

□ 

□ 

Precision agreement 
(VAX to IBM) 

□ 

□ 

□ 

□ 

Other: 

□ 

□ 

□ 

□ 


(Specify) 


6. Please estimate percentage of modules that will need changing. Changes 
Include any changes other than commentary. 

7. Please describe briefly any assumptions you made in the estimates. 
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APPENDIX D-MONTHLY STATUS REPORTS 


This appendix presents Monthly Status Reports submitted for the Ada rehosting 
study for the period from June 1989 through March 1990. 


v June 5 l 


This memorandum is to give you current status of Rehosting of GOES 
Telemetry Simulator from VAX/VMS environment to the IBM/MVS environment. 


o Received 24 questionnaires out of 31 

Average estimated effort: 168 staff days 

o Project started 4/17/89 

o Recoded 2 FORTRAN routines in Ada (6 routines were 4/25/89 

available from other source and modified) 

o Set up Source Library (PANVALET) 5/02/89 

o Coded and unit tested system dependent package 5/17/89 

Bit_OPS_System on the IBM 

o Transferred GOES IM source files via BFX (was not .5/22/89 

successful in transferring files using tape due to 
incompatibility between files on the VAX and IBM) 

o Compiled 37 units with 1 error which caused by 5/26/89 

Alsys Compiler restriction 

Total effort expended to 6/2: 23 staff days 


D-l 


5896 




ATTACHMENT 


July 13 r, /£??<? 


STATUS OF REHOSTING GOES TELEMETRY SIMULATOR 
IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer 


On VAX 


Needs Data 
Conversion 


Data File 
Converted 


Transferred 
to IBM 


Source Files 545 - - 545 
Data Files 3 2 1_ 0 
2. Function Requiring Rewrite or Change (VAX dependent) : 


# of New # of New 

Function Components Components 
Needed Completed 


Direct_IO 15 

Math_Lib 2 

Bit_Ops_System - 

Conversion of 2 

Fortran to Ada 

3. Compilation on IBM : 

No, Components on IBM 
No- Component compiled 
No- Errors 
No- Errors corrected 


15 

1 


# of 

Components 
Need to be 
Changed 


27 

2 

3 


562 

354 (63%) 
2 
2 


No- Components affected by errors 


4 . 

5- 

6 - 
7. 


Linkage on IBM 
Execution on IBM 
Testing on IBM 
Key Problems/Points : 


None to date 
None to date 
None to date 


# of 

Components 

Changed 


19 (70%) 

2 

3 


* There are unexpected problems occurring in the Alsys compiler 
and Program Library Manager which cause Ada Program Library 
to be corrupted- Alsys has been contacted. 
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July 13 , iqxq 

* The size for data objects allocated in the static part of the 
static frame is limited to 4k bytes, 

* There is no automatic recompilation provided. Obsolete units 
are deleted and must be recompiled individually. 

* There is no mechanism for multiple file compilation. 

* There is no bit level implementation for any of the 
representation clauses. 

* The minimum storage size associated with a type is 16 bits. 

Function written in Assembly Language to extract and store 
lower 8 bits from the simulated telemetry word( 16 bits on IBM) 
must be provided. 


Total time spent to 6/30 : 40 staff days 
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ATTACHMENT 


Aci^c/sf 7, 1929 


STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer : 


Source Files 

On VAX 
540 

Needs Data 
Conversion 

Data Files 

3 

2 


Data File 
Converted 


Transferred 
to IBM 
540 


1 


0 


2. Function Requiring Rewrite or Change (VAX dependent) : 





# of 


# of New 

# of New 

Components 

Function 

Components 

Components 

Need to be 


Needed 

Completed 

Changed 


i of ™ 
Components P 
Changed 


Direct_IO 19 

MathLib 2 

Bit_Ops_System 

Conversion of 9 

Fortran to Ada 

Ephemeris 3 

Database_Types 

Other 


19 27 

1 

2 

9 3 

3 

13 

14 


3. Compilation on IBM : 

No. Components on IBM : 553 
- No. Components compiled: 544 (98%) 

No. Components changed : 59 (11%) 

No. New Components : 33 (1830L0C) 

No. Errors : 3 

No. Errors corrected : 3 

No. Components affected by errors: 8 


4. Linkage on IBM 


None to date 


5. Execution on IBM 


None to date 


6. Testing on IBM 


None to date 


27 


2 

3 


13 

14 
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Key Problems/Points : 


flugusf % (m 


* Problems occurring in the Alsys compiler and Program Library 
Manager (reported last month) have caused additional problems this 
month. 

* Intermittant problem in unit testing (possible alsys compiler- 
problem) . 


Total time spent to 8/04 : 57 staff days 



ATTACHMENT 


September 1 

STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer : 


Needs Data 
On VAX Conversion 
Source Files 540 


Data File Transferred 
Converted to IBM 

540 


Data Files 3 


2 


2 


0 


2 , Function Requiring Rewrite or Change (VAX dependent) : 


Function 

# of New 

Components 

Needed 

i of New 

Components 

Completed 

# of 

Components 
Need to be 
Changed 

Direct_I0 

19 

19 

27 

Math_Lib 

2 

2 

- 

Bit_Ops_System 

- 

- 

2 

Conversion of 9 

Fortran to Ada 

9 

3 

Ephemeris 

3 

3 

3 

Database_Type$ 

- 

- 

13 

Other 

- 

- 

14 

3.. Compilation 

on IBM : 

(Completed) 



No. Components on IBM : 553 

No. Components compiled: 553 

No. Components changed : 62 

No. New Components : 33 (1830 LOC) 

No". Errors : 3 

No. Errors corrected : 3 

No. Components affected by errors: 11 


4. 

Linkage on 

IBM 

: Successfully Linked (Completed) 

5. 

Execution 

on IBM 

: Attempts Initiated 8/28 




6 Execution to Date 




All have abended 

6. 

Testing on 

IBM 

: None to date 


# of 

Components 

Changed 


27 


2 

3 

3 

13 

14 


19?9 


7. Key Problems/Points : 


Ssp-hember 7 , 


* Unusual Abends in Attempting Execution: 

- Return Code 4095 (Nothing explained in Manual) 

Increased Space Seemed to Resolve this 

- Return Code 15 (’Spurious Error’ - Unexpected Branch to Odd Address) 

Total time spent to 9/01 : 71 staff days 
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ATTACHMENT 


October 5 , 19 ?9 

STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer : 


On VAX 

Source Files 540 

Needs Data 
Conversion 

Data File 
Converted 

Transferred 
to IBM 
540 

Data Files 2 

2 

2 

2 

Namelist Files 33 

- 

- 

33 

2. Function Requiring Rewrite or Change 

(VAX dependent) 

• 

# of New 

Function Components 

Needed 

# of New 

Components 

Completed 

# of 

Components 
Need to be 
Changed 

# of 

Components 

Changed 

Direct JO 19 

19 

27 

27 

Math_Lib 2 

2 

- 

- 

Bit_Ops_System 

- 

2 

2 

Conversion of 9 

Fortran to Ada 

9 

3 

3 

Ephemeris 3 

3 

3 

3 

Databasejypes 

- 

16 

16 

Other 

- 

20 

20 


3. Compilation on IBM : (Completed) 

No. Components on IBM : 553 

No. Components compiled: 553 

No. Components changed : 71 

No. New Components : 38 (1830 LOC) 

No. Errors : 4 

No. Errors corrected : 4 

No. Components affected by errors: 12 


4. Linkage on IBM : Successfully Linked (Completed) 
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5. Execution on IBM : 17 Executions Attempted 

None Successful - All Have Abended 
See Key Problems 


6. Testing on IBM : None to date 


7. Key Problems/Points : 


Problems 


Solutions 


Compiler 
Probl em? 


* "Unexpected Branch 
to Odd Address" 
Problem occurred 
in array aggregates 

Replaced DVECTOR with 
DSCALAR when dimension 
is one 

Yes 

* "Constraint_Error" 
from Abstract_ 
Calendar. Split 

Corrected local variable 
type in Abstract_Calendar. 
Spl it 

No 

* "ConstraintError" 
from Debug Collector. 
Write 

Properly handled 
"Constraint_Error" 

No 

* Failed to check 
"End_Of_File" when 
reading Namelist 
file 

Modified to stop reading 
Namelist file when blank 
name returnd 

Possible 

* Failed to initialize 
Spacecraft Ephemeris 

Being investigated 

- 


Total time spent to 9/29 : 83 staff days 



ATTACHMENT 


f \Jot/ember £>, n 7S*9 

STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer : 


Source Files 

On VAX 
540 

Needs Data 
Conversion 

Data File 
Converted 

Transferred 
to IBM 
540 

Data Files 

2 

2 

2 

2 

Namelist Files 

33 

- 

_ 

33 


2. Function Requiring Rewrite or Change (VAX dependent) : 


# of New 

Function Components 
Needed 


Direct_I0 19 

Math_lib 2 

Bit_Ops_System 

Conversion of 9 

Fortran to Ada 


# of 

§ of New Components 
Components Need to be 
Completed Changed 


19 27 

2 

2 

9 3 


# of 

Components 

Changed 


27 


2 

3 


Ephemeris 3 


3 3 


3 


DatabaseTypes 


16 


20 


Other 


20 


28 


3. Compilation on IBM : (Completed) 

No. Components on IBM : 561 

No. Components compiled: 561 

No. Components changed : 83 

No. New Components : 41 (1830 LOC) 

No. Errors : 7 

No. Errors corrected : 7 

No. Components affected by errors: 16 


4. Linkage on IBM 


Successfully Linked (Completed) 
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K(yember \q%q 



5. Execution on IBM : 

Successfully Executed After 26 Attempts 
See Key Problems 

— 

6. Testing on IBM : 

Started Test 1.1 

Simulated Telemetry Output Does Not 
Match with Output From the Vax 


— 

7. Key Problems/Points : 



— 

Problems 

Solutions 

Compiler 

Problem? 

— 

* Failed to initialize 
Spacecraft Ephemeris 
- Problem occurred 
due to incorrect 
evaluation of 
"IF A <= 0.0" 

Rewrote IF statement 

Yes 

— 

* Incorrectly raised 
"Numeric_Error" in 
INTEGER computation 

Computed in REAL and 
converted back to INTEGER 

Yes 


* Failed to recompile Recompiled from the Body Yes 

subunit which has been 
previously compiled 


Total time spent to 11/03/89 : 92 staff days 
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ATTACHMENT 


December 6>, IQS9 


STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data 

File Transfer : (Completed) 




Needs Data 

Data File 

Transferred 


On VAX 

Conversion 

Converted 

to IBM 

Source Files 

540 

- 

- 

540 

Data Files 

2 

2 

2 

2 

Namelist Files 

33 

- 

- 

33 


2. Function Requiring Rewrite or Change {VAX dependent) 


# of New 

Function Components 

Needed 

# of New 

Components 

Completed 

# of 

Components 
Need to be 
Changed 

Direct_I0 

19 

19 

27 

Math_Lib 

2 

2 

- 

Bit_Ops_System 

• 

- 

2 

Conversion of 
Fortran to Ada 

9 

9 

3 

Ephemeris 

3 

3 

3 

Database_Types 

- 

- 

16 

Other 

_ 


20 


I of 

Components 

Changed 


27 


2 

3 

3 

22 

30 


3. Compilation on IBM : (Completed) 

No. Components on IBM : 562 

No. Components compiled: 562 

No. Components changed : 87 

No. New Components : 42 (1830 LOC) 

No. Errors : 7 

No. Errors corrected : 7 

No. Components affected by errors: 16 


4. Linkage on IBM : Successfully Linked (Completed) 

5. Execution on IBM : Successfully Executed After 26 Attempts 
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December 6 , 

6. Testing on IBM : Completed 4 out of 10 selected test cases. 

4 out of 5 output reports tested so far match 
Vax reports. Simulated Telemetry Reports 
partially matches Vax reports - being investigated 


Input Files 


Namelist File 
Attitude History File 
Dynamics Engineering File 
GOES Ephemeris File 
SLP file 

Output Reports 


Initialization Report 
Telemetry Record Report 
Simulated Telemetry Report 
Engineering Data Report 
Proc. Eng. Data Report 
Simulation Result Report 
Bit Flip Report 

Output Files 


Simulated Telemetry File 
Engineering Data File 
Proc. Eng. Data File 


Tested on 
the IBM? 

Match 

Vax Output? 

Yes 

Yes 

No 

- 

No 

- 

No 

- 

No 

- 


Yes 

Yes 

Yes 

Yes 

Yes 

No (Partially) 

Yes 

Yes 

Yes 

Yes 

No 

- 

No 

- 


Yes 

No (Partially) 

Yes 

Being verified 

Yes 

Being verified 


7. Key Problems/Points 
Problems 


Solutions 


Compiler 

Problem? 


Data_Error was raised Made same record length No 

when writing to for Header, Index, and 

Engineering Data File Data Record 
(D1rect_IO) 


8. Status 


Staff Days 20 40 


Complete | 

Source Transfer --+ 

Compilation 

Linkage 

Execution 


60 

I 1 

AA 

II 

II 

+1 

+ 


80 

I— -I 

A 


100 

-|-> 


im 


Total time spent to 12/01/89 : 103 staff days 



ATTACHMENT 


January 5 , IQQO 


STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


1. Source and Data File Transfer : (Completed) 


on vax 

Source Files 540 

Needs Data 
Conversion 

Data File 
Converted 

Transferred 
to IBM 
540 

Data Files 2 

2 

2 

2 

Namelist Files 33 

- 

- 

33 

2. Function Requiring Rewrite or Change 

(VAX dependent) 

; 

# of New 

Function Components 

Needed 

# of New 

Components 

Completed 

# of 

Components 
Need to be 
Changed 

# of 

Components 

Changed 

Direct_I0 19 

19 

27 

27 

Math_Lib 2 

2 

- 

- 

Bit_0ps_System 

- 

2 

2 

Conversion of 9 

Fortran to Ada 

9 

3 

3 

Ephemeris 3 

3 

3 

3 

Database_Types 

- 

16 

23 

Other 

_ 

20 

34 


3. Compilation on IBM : (Completed) 

No. Components on IBM : 562 

No. Components compiled: 562 

No. Components changed : 92 

No. New Components : 42 (1830 LOC) 

No. Errors : 7 

No. Errors corrected : 7 

No. Components affected by errors: 16 


4. Linkage on IBM : Successfully Linked (Completed) 

5. Execution on IBM : Successfully Executed After 26 Attempts 
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6. Testing on IBM 


January 5; (QQO 

: - Completed 7 out of 10 selected test cases 

- Successfully read SLP file 

- All output looks good except DSS data 

- Problem with Ephemeris File - getting 
IncorrectCoordException 




Tested on 

Match 



Input Files 

the IBM? 

Vax Output? 


— 

Namelist File 

Yes 

Yes 



Attitude History File 

No 

- 



Dynamics Engineering File 

No 

- 


- : : 

GOES Ephemeris File 

Yes 

No 



SLP file 

Yes 

Yes 


— 

Output Reports 




•— 

Initialization Report 

Yes 

Yes 



Telemetry Record Report 

Yes 

Yes 



Simulated Telemetry Report 

Yes 

Yes 



Engineering Data Report 

Yes 

Yes*(Except DSS data) 


Proc. Eng. Data Report 

Yes 

Yes* 


— 

Simulation Result Report 

Yes 

Yes* 



Bit Flip Report 

No 

- 



Output Files 




= — 

Simulated Telemetry File 

Yes 

Yes 


— 

Engineering Data File 

Yes 

Yes* 



Proc. Eng. Data File 

Yes 

Yes* 



7. Key Problems/Points : 








Compiler 


Problems 

Solutions 


Problem? 

= 

* -Incorrect results of 

Modified two 

routines 

No 


telemetry record (POCC) 

to incorporate the 


— 


difference in 

the type 



- Order of MSB and LSB 

definition 



— 

was reversed in the 





type BIT ARRAY 8 on 





the IBM. BIT ARRAY_8 




— - 

is predefine! VAX 





Hardware-oriented 





type 




— 

* Name_Error was raised 

Modified one 

routine to 

No 


when opening simulation 

correctly extend the file 



results report file 

name 
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January 5, /<?<?o 

* INCORRECT_COORD_SYSTEM being investigated ? 

is raised'when 

initializing Ephemeris 
variables 

* Wrong DSS data being investigated ? 


8. Status 

Average 

Estimate 

(168) 


Staff Days 


Complete 

Source Transfer 
Compilation 
Linkage 
Execution 
7 tests 


30 


60 

■I 1- 


90 


120 


150 

■I— -I- 


A 

I 

- + 


II 

II 

-+l 

--+ 


1 

-+ 


Total time spent to 12/29/89 : 113 staff days 


9. 


Performance 



(NAS 8063) 

(VAX 8810) 


IBM 

VAX 

Speed of CPU (MIPS) 

8.65 

6.36 

Compilation (Lines/Min) 

: 1295 

3618 

Binding/Linking (CPU Sec) 

: 64.20 

12.84 * 

Execution (CPU Sec) 

2 minute simulation 
with Direct_I0 only 

: 69.46 

89.68 

with Text_I0 only 

: 121.41 

63.87 

with both 10s 

: 169.29 

159.00 

without any 10 

: 17.87 

34.67 


* Computed based on the previous statistics that it takes 5 times 
more CPU times on the IBM than on the VAX 
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ATTACHMENT 


February Hj IQQO 

STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN AOA FROM VAX TO IBM 


1. Source and Oata File Transfer : (Completed) 





Needs Data 

Oata File 

Transferred 



On Mi 

Conversion 

Cpnvert^ 

io IBM 


Source Files 

540 

- 

- 

540 


Data Files 

2 

2 

2 

2 


Namelist Files 33 


- 

33 


2. Function Requiring Rewrite or Change 

(VAX dependent) 


— 




# of 



# 

of New 

# of New 

Components 

# of 



Function Components 

Components 

Need to be 

Components 

— 

Needed 

Completed 

Changed 

Changed 


01rect_I0 

19 

19 

27 

27 

— 

Math_Lib 

2 

2 

- 

- 


Bit_Ops_System 

- 

- 

2 

2 

— 

Conversion of 

9 

9 

3 

3 


Fortran to Ada 

> 




w 

Ephemeris 

4 

4 

3 

3 

— 

DatabaseJTypes 

- 

- 

23 

23 

-■ " 

Other 

11 

11 

40 

40 


3. Compilation on IBM : (Completed) 

No. Components on IBM : 564 

No. Components compiled: 564 

No. Components changed : 98 

No. New Components : 45 (1970 LOC) 

No. Errors : 7 

No. Errors corrected : 7 

No. Components affected by errors: 16 


4. Linkage on IBM 


Successfully Linked (Completed) 


5. Execution on IBM 


Successfully Executed After 26 Attempts 
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February % iQ^O 

6. Testing on IBM : - Completed all 10 selected test cases 

- Successfully read GOES Ephemeris File 

- Have problems with Dynamics Engineering File 



Tested on 

Match 

Input Files 

the IBM? 

Vax Output? 

Namelist File 

Yes 

Yes 

Attitude History File 

Yes 

Yes - - 

Dynamics Engineering File 

Yes 

No 

GOES Ephemeris File 

Yes 

Yes 

SLP file 

Yes 

Yes 

Output Reports 

Initialization Report 

Yes 

Yes 

Telemetry Record Report 

Yes 

Yes 

Simulated Telemetry Report 

Yes 

Yes 

Engineering Data Report 

Yes 

Yes 

Proc. Eng. Data Report 

Yes 

Yes 

Simulation Result Report 

Yes 

Yes 

Bit Flip Report 
Output Files 

Yes 

Partial ly 

(Due to RANDOM number) 

Simulated Telemetry File 

Yes 

Yes 

Engineering Data File 

Yes 

Yes 

Proc. Eng. Data File 

Yes 

Yes 


7. Key Problems/Points : 

Compi 1 er 

Problems Solutions Problem? 


* INCORRECT_COORD_SYSTEM Replaced STRING No 

is raised when reading with EBCDIC. STRING 

-IBM resident GOES 
Ephemeris File 

* Incorrectly Reads - Yes 

Dynamics Engineering 

File Header and Data 
records 

- Have a problem with 
reading records starting 
with INTEGER or $H0RT_ 

FLOAT (4 bytes) followed 
by FLOAT (8 bytes) 
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8. Status 


Staff Days 0 30 


Complete | 

Source Transfer --+ 
Compilation — 

Linkage — 

Execution — 

10 tests 


60 

I— - 

A A 

II 

II 

— +1 
+ 


90 


February q / iqqo 

Average 

Estimate 

(168) 


120 150 v 


+ 


Total time spent to 2/2/90 : 128 staff days 
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ATTACHMENT 


March 6, mo 


STATUS OF REHOSTING GOES TELEMETRY SIMULATOR IN ADA FROM VAX TO IBM 


A. Source and Data File Transfer 


Source files transferred 
Data files converted to IBM format 
Input data files transferred 
Major problems 


540 (some files were not used) 


2 

35 

NONE 


B. Compilation on IBM 


# of components compiled 

# of components changed 

# of new components added 
Average compilation speed 
Major problem 


564 

102 

45 (1970 LOC) 

1295 1 ines/minute 

library corruption, compiler limitation 


C. Linkage 


Attempts made to successfully link 
Average bind/1 ink speed 
Major problems 


: 1 

: 64.2 cpu seconds 
: NONE 



C. Execution 

Number of attempts made to 

successfully execute TEST 1 : 26 

Number of compiler problem found : 7 

Major problems : compiler errors, software errors 



E. Testing 

# of test cases executed : 10 

# of input files successfully read : 4 out of 5 

# of output files successfully written : 10 out of 10 
Execution speed in cpu seconds (2 minute simulation) : 

with Direct_I0 only : 69.46 

with Text_I0 only : 121.41 

with both 10 : 169.29 

with any 10 : 17.87 

Accuracy of results compared to VAX : matched to 4 - 5 digits 
Major problems : compiler error, file interface 
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Compiler problems found during rehosting 


March £>, 19 90 


1. CPU timeout caused Ada Program Library to be corrupted 

2. Incorrectly evaluated "if A >= 1.0" 

3. Incorrectly raised "Numeric_Error" in INTEGER computation 

4. Raised "Spurious_Error" due to branch to odd address 

5. Skipped first record when reading direct access file written 
by non -Ada program 

6. Incorrectly read direct access file starting with INTEGER 
followed by FLOAT even with record representation clause 


G. Staff days to complete each phase 


Staff Days 0 


30 


| 1 1 1 . 


60 

-I— -I 


90 


Complete | 

Source Transfer --+ 
Compilation — 

Linkage — 

Execution — 

10 tests — 

Draft Report — 


+ 1 
-+ 


I 


+ 


120 

-I— -I 

A A 


150 


Average 

Estimate 

(168) 


v 


+ 


+ 


Congratulations to the following people who gave the best estimates 
on the rehosting effort. 

Actual effort including report draft : 133 staff days 


F. McGarry/552 

130 

E. Booth/CSC 

130 

S. Watson/552 

137 

D. Wood/CSC 

144 
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GLOSSARY 


asch 

CPU 

DEC 

EBCDIC 

FDD 

GOES 

GOESM 

GSFC 

I/O 

KSLOC 

NAS 

NASA 

SEL 

SLOC 


American Standard Code for Information Interchange 

central processing unit 

Digital Equipment Corporation 

Extended Binary Coded Decimal Interchange Code 

Flight Dynamics Division 

Geostationary Operational Environmental Satellite 

GOES telemetry simulator 

Goddard Space Flight Center 

input/output 

thousand SLOC 

National Advanced Systems 

National Aeronautics and Space Administration 

Software Engineering Laboratory 

source lines of code 
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